IBIS Macromodel Task Group Meeting date: 20 May 2014 Members (asterisk for those attending): Agilent: Fangyi Rao * Radek Biernacki Altera: David Banas ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) * Xingdong Dai Cadence Design Systems: * Ambrish Varma Brad Brim * Kumar Keshavan * Ken Willis * Scott Huss Ericsson: Anders Ekholm Intel: * Michael Mirmak Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz * Todd Westerhoff * Mike LaBonte Teraspeed Consulting Group: Scott McMorrow * Bob Ross Texas Instruments * Alfred Chong The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - Arpad: I sent personal invitations to IC vendors to join us today. - Michael M: The DAC IBIS summit will be June 5. - We have room for more presentations and sponsors. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - None ------------- New Discussion: SPI summit last week in Europe: - Randy: There were mostly SPI attendees, many familiar faces. - Wael Dghais gave a presentation on alternate IBIS algorithms. - This is a common theme for European summits. - Wael has presented on this before. - It has Y/Z and Q/Z tables, extracts from S-parameters. - He would like to know if IBIS is interested in this. - His paper will be on the IBIS website. - They look forward to regular IBIS specification releases. Backchannel proposals: - Arpad: There was a motion last week to decide between BIRD 147 and Walter's proposal. - We can have more discussion first. - David: Walter's proposal is rigid in the manner that a TX describes its capabilities. - BIRD 147 protects me from being tied to that. - Walter: Most TX models have some number of pre and post taps with coefficient ranges. - Training protocols either increment, decrement, or set tap coefficients. - Any existing TX that has those can be trained without knowing the protocol. - If it doesn't have those things it probably is not trainable. - David: On Walter's slide 8 it says taps maintain peak-to-peak voltage. - We may not want to take away the freedom to meet that in different manners. - This proposal wants to send commands to change Vod. - I would have to re-architect my models to handle this. - Walter: You would expose your taps to be adjustable. - The model itself maintains peak-to-peak voltage. - The sum is always one and taps are adjusted accordingly. - David: We divide analog and EQ behaviors. - It could be a problem if the model was told to change analog behavior. - Todd: The model must produce a physically realizable output. - David: Will the EDA tool be "too helpful" and make changes for me? - Walter: The TX can refuse to make some requested changes. - It will tell the RX what it really did. - David: Then my TX is at the mercy of the EDA tool, changing my Vod. - Walter: Some existing models will change peak-to-peak voltage as you change taps. - David: I had claimed the Cadence proposal has extra indirection, is that true? - Will BIRD 147 protect from this? - Ambrish: Our entire job is to open a channel for TX/RX communication. - The EDA tool does not get in between the TX and RX. - David: So the TX will have to be modified? - Ambrish: Yes it must be a black box. - Walter: Then you are at the mercy of the RX. - Kumar: It is not the tool's business to know the architecture. - Ambrish: The TX may ignore tap change suggestions. - Kumar: A robust RX will not assume the TX has done something. - It must analyze the waveform. Arpad showed Walter's presentation: - Alfred: The MAC layer has to establish communication. - The IP vendor decides how to achieve desired voltage output. - An ordinary TX can probably do this. - We should not need a BCI file, but that would be OK. - In link training the RX must reach steady state. - That can take very long, will we still use Ignore_Bits? - Frame markers are needed to separate training phases. - It would be overkill to implement that though. - Link training is proprietary. - The communication may help to guess the algorithm. - We have to address presets, Walter's proposal has that. - For statistical most settings are digital, we don't need to identify coefficients. - The Cadence proposal is not clear about that. - Ambrish: The BCI file standardizes the process. - You can have proprietary training. - The BCI file can capture it. - Arpad: The question of Ignore_Bits is interesting. - Ambrish: The BIRD mentions that. - Walter: The Cadence approach is limited to solving how well the RX trains the TX. - Another problem is finding what the optimal tap coefficients are without running the training algorithm. - The RX can say the exact tap coefficients it wants. - Another way is to increment and decrement. - Proprietary training may be entirely inside the RX. - You can set registers and not be constrained by any protocol. - Ignore_Bits is up to the RX, it decides when to set coefficients. - Ambrish: That is covered in BIRD 147 page 9. - Walter: Cadence proposed a complicated training pattern syntax, is that necessary? - Would PRBS11, PRBS17 be sufficient? - Alfred: The pattern is usually PRBS11 for KR. - PRBS31 can be a replacement for the pattern for PCIe . - Finding the optimal operating point would be very useful. - Will there be enough time in training to adapt to minor changes? - Making the wrong changes can mess up the CDR. - It would help to reset to initial settings. - Walter: Both proposals would allow the RX to reset the TX and reset or not reset DFE settings. - Todd: BIRD 147 page 9 does not allowing for settling the RX after training. - Mike L: There could be multiple BCI files for any protocol. - Ambrish: We would work that out and settle on one. - Bob: We haven't worked out what to do about a parser for BCI files. - With Walter's proposal would the protocol be in the RX AMI file? - Walter: Only special text strings to pass back and forth would need anything in AMI. - Ambrish: How would you accommodate multiple protocols in one model? - Walter: With a protocol name parameter. - To be correct even LFSR can't describe everything. - Arpad motioned to table the vote for today,until the next meeting. - David seconded. - No one objected. - Scott: It would not be appropriate to use standard PRBS23 for PCIe. - Can the TX communication rejections back to the RX? - Are limits confined to a single tap or are they multi-dimensional? - David: They almost always depend on amplitude. - Scott: The RX may not know why the TX reached a limit, and that matters. - David: Cadence proposes the RX would keep trying and eventually give up. - Walter: Both proposals address this. - The RX receives info on what the TX actually did. - Specific bit patterns might have to be a file of zeros and ones. - It might be scrambled, for exampled. - TX taps can have coefficients not allowed for current conditions. - This should be in the TX DLL. - Arpad: Resolve might be able to help. - Walter: That may be complex. - Scott: Could have have equations to define tap limits? - Walter: That can be complex, difficult to put in a protocol. - Michael M: Are there constraints on indexes? - Scott: There are not hard limits on each tap. - Michael M: The endpoints are integers, not float. - Walter: The coefficients really are a poor man's floating point number. - Michael M: The conversions back and forth are critical. - There can be quantization error. ------------- Next meeting: 13 May 2014 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives